Magnum One

home *** CD-ROM | disk | FTP | other *** search

/ Magnum One / Magnum One (Mid-American Digital) (Disc Manufacturing).iso / d21 / tips0815.arc / TIPS0815.ASC < prev

Wrap

Text File | 1990-09-14 | 42KB | 842 lines

Tips by Craig S. Stevenson using: HARDWARE SOFTWARE USR Courier Dual Standard DesqView 2.25, 2.26 USR Courier HST 14400 QEMM 4.23, QEMM 5.00 Zenith Z386-25 Manifest 1.00 Zenith Z386-12 PCTools Deluxe 5.5, 6.0 Zenith Z286-12 RBBS-PC 17.3 /0227 /0518 /ANSIED Zenith Z286-8 Doorway 2.05, 2.06 Beta Zenith Z159-8 X00.SYS Version 1.22, 1.23H Zenith Turbosport 386 ADCACHE Version 1.20 DTK 386-25 SUPER-PC-KWIK Version 1.54 DSZ Version 4-11, 6-26 Windows 3.0 Reconfig 3.1 ZDOS 3.3+, ZDOS 4.01 From: The Bertha BBS (218)-924-2060 Date: August 15, 1990 The current version of TIPS is available to subscribers of The Bertha BBS. Disclaimer: Use the tips at your own risk! I have tried to be accurate in my diagnosis of problems and their solutions. However, it is impossible to know everything about your machine. These tips worked on my machines, they may not work on yours due to some unforeseen differences. Neither I, nor The Bertha BBS will be held responsible for damages done by anything you do to your machine. Distribution: This file may be distributed on BBS's as long as it is not modified in any way. ══════════════════════════════════════════════════════════════════════════════ ┌───────────┐ │ TIP INDEX │ └───────────┘ ══════════════════════════════════════════════════════════════════════════════ Category Tip# Problem ------------- ---- ------------------------------------------------------- QEMM/DesqView 1 Repeated system hangs when using DesqView. QEMM/DesqView 2 High speed communications causing hangs within DV. QEMM/DesqView 3 Print screen causing hangs in DesqView 2.26. QEMM/DesqView 4 System hangs when using PCTools Deluxe V6.0 in DV. QEMM/DesqView 5 Getting a caching program to work with DesqView. QEMM/DesqView 6 Acquiring more high ram. QEMM/DesqView 7 Communications program causing system slowdown in DV. QEMM/DesqView 8 Increasing DesqView window sizes. (Using Zenith DOS) QEMM/DesqView 9 Larger DV windows and more high ram. (Zenith only) QEMM/DesqView 10 Intermittent DesqView problems. QEMM/DesqView 11 "Drive x Not Ready" error message from hard disk drive. QEMM/DesqView 12 System hangs and file corruption. Zenith 1 System hangs when doing a warm boot with QEMM 5.0. Zenith 2 Slow video after installing QEMM 5.0. Zenith 3 Increasing memory size for applications. Zenith 4 "Unable to read sector" error message from PCTools. Zenith 5 "Error, Keyboard Not Connected" error message. Zenith 6 Slow hard drive access on Zenith Turbosport. RBBS-PC 1 DV applications interfering with user communications. RBBS-PC 2 Poor performance of RBBS when using multiple nodes. RBBS-PC 3 Optimizing performance with X00.SYS. Communications 1 MNP-5 modem connection problems. Communications 2 Slow download speeds when using 2400 baud MNP-5 modems. Communications 3 Slow download speeds from some USR HST boards. Communications 4 DSZ/Zmodem will not work on my system. Doorway 1 Screen problems when using Doorway under DesqView. Doorway 2 Typing during screen update produces garbage on screen. Reconfig 1 Reconfig not working properly when caching enabled. Hardware 1 Floppy/Hard drives not working properly. ══════════════════════════════════════════════════════════════════════════════ ┌───────────────┐ │ QEMM/DesqView │ └───────────────┘ ══════════════════════════════════════════════════════════════════════════════ ┌───────────────────────┐ │ QEMM/DesqView TIP# 1 │ └───────────────────────┘ PROBLEM: Repeated system hangs when using DesqView. SYMPTOMS: System will hang intermittently and with no warning. SOLUTION: Check the setting of "Manage Printer Contention" in the DesqView Setup area. Numerous hangs are caused by having this set to "Y". Set it to "N". You must make sure not to have two applications printing at the same time. NOTE: The solution that I use for this problem is to use a buffer on the printer. Mine is 512K. That way I can print and the buffer takes all the data. Then I can close the window and print something else from another application immediately. ══════════════════════════════════════════════════════════════════════════════ ┌───────────────────────┐ │ QEMM/DesqView TIP# 2 │ └───────────────────────┘ PROBLEM: System hangs when using high speed communications within DesqView. SYMPTOMS: When running high speed (>9600 baud) communications, the system will hang intermittently. SOLUTION: Switch to buffered (16550) serial ports. On my system, I was able to move to 19200 baud with no hangs by switching to the buffered ports. You may also try setting "Optimize Communications" to Y in the DesqView Setup area. Be cautious with this setting as it can cause some problems as well. It is also helpful to upgrade to DesqView 2.26 as there is better support for high speed communications. NOTE: I have now gone to 38400 baud on my system using the X00 FOSSIL driver. Things seem to be operating smoothly. ══════════════════════════════════════════════════════════════════════════════ ┌───────────────────────┐ │ QEMM/DesqView TIP# 3 │ └───────────────────────┘ PROBLEM: When I do a print screen in DesqView 2.26, my computer hangs. SYMPTOMS: Pressing the print screen key while using DesqView 2.26, part of the screen will print and then the computer hangs up. Even CTRL- ALT-DEL will not reset the machine. SOLUTION: DesqView 2.26 uses a different method to do a printscreen. There is a patch available to change back to the old way of doing it. Patch your program and the problem will go away. ══════════════════════════════════════════════════════════════════════════════ ┌───────────────────────┐ │ QEMM/DesqView TIP# 4 │ └───────────────────────┘ PROBLEM: System hangs when using PCTools Deluxe Version 6 within DesqView. SYMPTOMS: If you try to delete multiple files with PCShell, the system will hang after deleting the first or second file. Sometimes you will be able to get to the DesqView Menu, but you will get an error message when you try to open another window. SOLUTION: The problem seems to be isolated to the Delete Tracking option of Mirror. You may use Mirror, but do not use the Delete Tracking Option. NOTE: Some additional information on this problem. When you use mirror with the delete tracking option, mirror sets up a TSR. This TSR is what gives DesqView fits. When you just use mirror without delete tracking, no TSR is needed. So mirror works fine without delete tracking. ══════════════════════════════════════════════════════════════════════════════ ┌───────────────────────┐ │ QEMM/DesqView TIP# 5 │ └───────────────────────┘ PROBLEM: I can't get a caching program to work properly with DesqView. SYMPTOMS: After loading PC-Cache version 6, the cache does not work if you enter DesqView directly. If you use manifest to look at First Meg Programs, PC-CACHE is not listed. SOLUTION: I was not able to get PC-Cache version 6 to work correctly on my system. Either switch back to version 5.5 or get a shareware copy of ADCACHE. ADCACHE was written with QEMM, 386-to-the-max, and DesqView in mind. It is fast, small, and compatible. NOTE: I have also used Super PC-Kwik with success. It is larger than ADCACHE, but it is somewhat faster. ══════════════════════════════════════════════════════════════════════════════ ┌───────────────────────┐ │ QEMM/DesqView TIP# 6 │ └───────────────────────┘ PROBLEM: I can't seem to get enough high ram to load all the things I want to load high. SYMPTOMS: Insufficient high ram available to load applications. SOLUTION: If you have a color system (EGA/VGA) and never use monochrome, use the I=B000-B7FF switch on QEMM to include the monochrome video area. This will gain you 32K of high ram. ══════════════════════════════════════════════════════════════════════════════ ┌───────────────────────┐ │ QEMM/DesqView TIP# 7 │ └───────────────────────┘ PROBLEM: Other DesqView windows operations grind to a halt when using a communications program in the foreground. SYMPTOMS: Severe performance degradation when using a communications program in another window. SOLUTION: Use Tame on your communications program to make it release the clock-ticks it doesn't need. It made about 400 cps difference on my system. NOTE: Tame 2.30 has its defaults set differently than 2.20. This means that you may have to fine tune it to work correctly. ══════════════════════════════════════════════════════════════════════════════ ┌───────────────────────┐ │ QEMM/DesqView TIP# 8 │ └───────────────────────┘ PROBLEM: I can't get enough memory freed up to open the size windows that I need to run my applications. I use Zenith Dos. SYMPTOMS: Window sizes are difficult to get above 460K due to the overhead of DOS, Video, Drivers, Etc. SOLUTION: If you are using Zenith Dos 3.3+, switch to Zenith Dos 4.01. Dos 4.01 is about 40K smaller than the later versions of 3.3+. That made my windows about 20K larger than before, leaving me more room to increase the size of my transmit and receive buffers. IBM Dos 4.01 is supposedly larger than 3.3, but Zenith Dos 4.01 is smaller. Zenith Dos 4.01 also appears to be free of most of the bugs in IBM Dos 4.01. NOTE: Different versions of Zenith Dos 3.3+ were different sizes. For example, doing a plain hard drive boot with no Autoexec.Bat and Buffers=8, Files=20 in Config.Sys the amount of memory remaining is as follows: Dos 3.30 / 3.30.08 (599,600 free) Dos 3.30 / 3.30.14 (562,064 free) Dos 4.01 / 4.00.02 (590,336 free) The later versions of Dos 3.3+ appear to be larger. I upgraded from Dos 3.30 / 3.30.14 to Dos 4.01. I gained about 28K with the upgrade. If you have an earlier version of Dos 3.3+, you may not benefit. To see what version of Dos you have, type VER from the dos prompt. ══════════════════════════════════════════════════════════════════════════════ ┌───────────────────────┐ │ QEMM/DesqView TIP# 9 │ └───────────────────────┘ PROBLEM: I am still fighting for larger windows and more high ram. I use a Zenith computer with a Zenith/DTC Hard/Floppy controller. SYMPTOMS: There is not enough free high ram to get the DesqView windows as large as I want to. SOLUTION: If (and only if) you use a Zenith computer with a Zenith/DTC controller, you may be able to include part or all of the C800-CFFF range to use as high ram. Zenith/DTC controllers normally do not have a BIOS on them. Disk I/O is handled by the Zenith BIOS. As a result you can use I=C800-CFFF on your QEMM line in order to gain another 32k of high ram. This should help your window size as well. Beware of other cards that may reside in that space. You may have a SCSI card there or something else. To make sure, use Manifest to see if there is anything in that space. ══════════════════════════════════════════════════════════════════════════════ ┌───────────────────────┐ │ QEMM/DesqView TIP# 10 │ └───────────────────────┘ PROBLEM: I get intermittent "weird" things that happen to my computer when I run DesqView. SYMPTOMS: Sometimes the system will "hang", other times it will do strange things. SOLUTION: I have heard of a number of problems being solved by using the NOSORT (NS) switch in QEMM 5.0. QEMM normally "sorts" the memory in your machine by speed. Some programs have a problem with memory that has been "sorted" by QEMM since the memory may not be contiguous. I use this switch with no problems, but cannot verify that it solved anything. ══════════════════════════════════════════════════════════════════════════════ ┌───────────────────────┐ │ QEMM/DesqView TIP# 11 │ └───────────────────────┘ PROBLEM: I get a "Drive x Not Ready" error message from my hard disk. SYMPTOMS: When doing disk intensive work in an application, a "Drive x Not Ready", "Abort, Retry, Fail?" error message will occur. By typing "R" to retry, the program continues normally until the next occurance. SOLUTION: This error message occurs primarily with IDE drives, although any 1:1 interleaved drive may be affected. The problem is in the overhead that QEMM requires to operate. This is a problem that Quarterdeck has finally been able to reproduce, and they are working on it. If you do not have an IDE drive, you may be able to reformat you hard disk to 2:1 or 3:1 interleave. This will cause the drive and controller to be less timing critical. For an IDE drive, this is not possible. Some drives allow you to change a jumper on the drive to emulate 2:1 interleave. It is unclear whether this works or not. I have not tried this method. There are also some timing problems with some BIOS's. An upgrade to the most current revision might help the problem. Quarterdeck also suggests using Stacks=0,0 to reduce the DOS overhead. This promises to be an ongoing battle. Stay tuned... NOTE: If you have a machine with AMI Bios, you might try the following: In the advanced setup there is an entry called "16-bit AT command delay 00 00 01 01". Change this to "00 01 01 01". This is supposed to completely solve the IDE timout problem. I haven't verified this, since I don't have a machine with AMI Bios. ══════════════════════════════════════════════════════════════════════════════ ┌───────────────────────┐ │ QEMM/DesqView TIP# 12 │ └───────────────────────┘ PROBLEM: System hangs and file corruption occur when running under DesqView. SYMPTOMS: Intermittent system hangs when operating with DesqView. Sometimes files will be corrupted. Usually unable to reproduce the problem consistently. SOLUTION: Check your interrupts! Interrupt conflicts can cause all sorts of strange problems. I still see people recommend using IRQ2 on an AT class machine. IRQ2 is a cascaded interrupt for IRQ8 through IRQ15 and cannot be used. A lot of us upgraded from an XT and are used to setting our systems up to use IRQ2. I moved my bus mouse card from an XT to an AT and had all sorts of problems until I changed the interrupt from IRQ2 to something that was not being used. ══════════════════════════════════════════════════════════════════════════════ ┌────────┐ │ Zenith │ └────────┘ ══════════════════════════════════════════════════════════════════════════════ ┌────────────────┐ │ Zenith TIP# 1 │ └────────────────┘ PROBLEM: System hangs when using QEMM 5.0 and doing a warm boot on Zenith machines. SYMPTOMS: When requesting a CTRL-ALT-DEL reboot, the system hangs. You must then power down to reset. SOLUTION: Use the NOROM (NR) switch in QEMM 5.0. QEMM normally maps one 4k segment of the BIOS rom in order to detect reboots. Because of the way Zenith handles reboots, you must defeat this with the NOROM switch. ══════════════════════════════════════════════════════════════════════════════ ┌────────────────┐ │ Zenith TIP# 2 │ └────────────────┘ PROBLEM: Video seems slow after installing QEMM 5.0 on Zenith machines equipped with Z-549 or Z-449 video cards. SYMPTOMS: Screen update speed is very slow. When you run a benchmark the BIOS video speeds are very slow. SOLUTION: Zenith normally maps the VGA and EGA roms to RAM in order to speed up their access. Compaq does things similarly, but not identically. You must use the NOCOMPACFEATURES (NCF) switch to defeat this. Your video should return to the correct speed. You must also exclude C000-C7FF and E000-E7FF with the X=C000-C7FF and X=E000-E7FF switches in order to make room for the video slush area. NOTE: If you have a Zenith Z-449 EGA card, you need to exclude C000-C3FF. You must still exclude E000-E7FF. ══════════════════════════════════════════════════════════════════════════════ ┌────────────────┐ │ Zenith TIP# 3 │ └────────────────┘ PROBLEM: I can't get enough memory free to run the applications I want to run when using a Zenith computer. SYMPTOMS: After setting up DesqView, my window size is limited to about 480K. Nothing I do seems to be able to raise it much above that. SOLUTION: There are two solutions that I have used with success. These solutions only apply if you have a Zenith 386 computer and a Z-549 VGA video card. Zenith normally "slushes" the Video ROM to E000-E7FF. A pointer is changed so that applications expect to find the ROM at that location. You can include the area from C100-C5FF with the I=C100- C5FF switch on the QEMM command line. This adds 20K of extra high RAM. Video speed is not affected by using this area, since the ROM has been slushed to the E000 area. The second solution is more elegant. There is a file on the Bertha BBS called UNSLUSH.ZIP. This file contains a program which changes the pointer back to the C000 paragraph and as a result does not use the E000-E7FF area. Video slushing still occurs, but since the pointer has been changed back to C000, the E000-E7FF area can now be mapped over with RAM by QEMM for its high RAM. The only problem is that BIOS video calls will be agonizingly slow. The solution is to have QEMM map the video ROM into RAM using the ROM=C000-C7FF switch. Your Config.Sys should contain the following: DEVICE=C:\UNSLUSHV.SYS DEVICE=C:\QEMM.SYS ON NCF NR ROM=C000-C7FF RAM This should give you an extra 32K of high RAM with no degradation of video performance. Note that you should include the NCF and NR switches on Zenith machines. These are explained in another area of this file. ══════════════════════════════════════════════════════════════════════════════ ┌────────────────┐ │ Zenith TIP# 4 │ └────────────────┘ PROBLEM: When running PC Shell 6.0 on my Zenith system I get an "Unable To Read Sector" error message. The disk verifies fine with Diskfix or other utilities. SYMPTOMS: It appears that a file is bad when using PC Shells File Verify option. Usually this is noticed when copying a file from one area of the hard drive to another. However, when a surface scan is done, nothing is found. SOLUTION: On one of my systems the above problem which appeared initially as a hardware problem, turned out to be a problem with ADCACHE. I use ADCACHE on my BBS with no problems. For some (as yet unknown) reason, when I switched to a DTC ESDI controller and a 150 MEG drive, the problem appeared. ADCACHE was used successfully on the same machine with a DTC 7280 1:1 controller and 90 MEG drive. My solution was to switch to Super PC-Kwik. I am not convinced that the total problem was with ADCACHE, but I could not find any other problems with the machine. More to come... ══════════════════════════════════════════════════════════════════════════════ ┌────────────────┐ │ Zenith TIP# 5 │ └────────────────┘ PROBLEM: I keep getting an "Error, keyboard not responding or not connected" error message on my Zenith computer. SYMPTOMS: The above error message appears when doing a cold boot of the computer system. It may not happen all the time. It may occur with Zenith or clone keyboards. SOLUTION: The problem is in the keyboard reset circuitry. A look at the schematic for a Zenith ZKB-2 keyboard shows that pin 1 of the keyboard processor is used to provide a power-up reset to the processor itself. When power is first applies, capacitor C8 is totally discharged. This capacitor is charged through the keyboard processor towards five volts. Because of the capacitance, the charging is delayed and is held low long enough to provide the power-on reset. However, if the capacitor charges up too far towards five volts before the processor is ready, the reset signal is missed. A related factor may be the amount of memory and peripherals that you have in your computer. My problem surfaced after adding memory and a larger hard drive. It may be that the five volt supply does not come up as fast as normal due to the increased load. In my Zenith keyboard there is a 2.2 uf capacitor at C8. Electrolytics are notorious for changing their value dramatically with age. I also believe that raising the value from 2.2 to something in the 4.7 - 10 uf range would allow a much better chance for the keyboard processor to be properly reset. I also had a clone keyboard which would never be "seen" by the Zenith Z386-25 machine that I was using it on. This unit had a 4.7 uf tantalum capacitor on the processor reset pin. This had to be increased substantially in order for the keyboard to work properly. I went as high as 35 uf with no problems. The keyboard took a relatively long time to reset, but it worked fine, every time. If you do decide to replace the capacitor, observe proper polarity for either electrolytics or tantalums. If you are a hacker type, give it a try. Otherwise you can do what I did and order an upgraded BIOS, SCP, and then find out that a fifty cent part was giving you grief. NOTE: Originally it looks as if the computer was supposed to provide the reset signal for the keyboard, but in my ZKB-2 that jumper was not installed. My guess is that the reset signal is no longer supplied by the computer. ══════════════════════════════════════════════════════════════════════════════ ┌────────────────┐ │ Zenith TIP# 6 │ └────────────────┘ PROBLEM: The hard disk on my Zenith Turbosport seems slow. SYMPTOMS: Access to the hard drive seems slow compared to what it should be. SOLUTION: There was a bug in the BIOS Rom of the Turbosport. This was fixed with ROM revision 444-651-3. Call Heath/Zenith parts and get an upgrade. ══════════════════════════════════════════════════════════════════════════════ ┌─────────┐ │ RBBS-PC │ └─────────┘ ══════════════════════════════════════════════════════════════════════════════ ┌─────────────────┐ │ RBBS-PC TIP# 1 │ └─────────────────┘ PROBLEM: When I run RBBS-PC and someone does a download or upload, I can't open another DesqView window without interfering with their communications. I have replaced my UARTS with 16550's. SYMPTOMS: When a user on one node of RBBS-PC is uploading or downloading, opening another window will introduce CRC errors into their transmission. This occurs on the internal protocols (Xmodem, Ymodem, Ascii). SOLUTION: This is a very obscure problem which does not have an obvious answer. The problem is that RBBS-PC by itself does not initialize the 16550 chips. Therefore the internal protocols do not benefit from the buffering. External protocols such as Zmodem, YmodemG, and others have a program such as DSZ to initialize the 16550. The solution is to use a fossil driver such as X00 to initialize the 16550 chips. This will make them available to the internal protocols as well. ══════════════════════════════════════════════════════════════════════════════ ┌─────────────────┐ │ RBBS-PC TIP# 2 │ └─────────────────┘ PROBLEM: The performance of RBBS-PC seems slow when using two or more nodes under DesqView. SYMPTOMS: The BBS seems to be slow in doing file accesses, screen updates, etc. SOLUTION: There are several things which can be done to improve the performance of RBBS-PC under DesqView. You must be fairly well versed in DOS, RBBS, and DesqView/QEMM in order to accomplish your goal effectively. Remember that DesqView splits up your computer resources among the applications that you have opened. The more efficiently that your computer operates, the more resources will be available to your programs. 1. Use a cache. This makes a big difference in disk access. I use ADCACHE on my board. The cache sits in expanded memory and is 2 megabytes. I get track hits of about 95 percent. That saves a lot of time when trying to do several things at once. Do NOT use write caching, especially under DesqView. If you use write caching, you may corrupt your FAT. If you use a fairly large cache, you should be able to reduce the size of your DOS buffers. I use Buffers=4 in my Config.Sys. This increases the available memory to your system. I do not recommend loading buffers high or using Quarterdeck's Buffers.Com. I have heard of some strange things happening for those who do. NOTE: I have switched to Super PC-Kwik Cache. It is faster than ADCACHE and seems to be aware of more hardware and software combinations. I have also increased the size of the cache to 3 megabytes. 2. Use a ramdisk. Some of the RBBS files may be put in a ramdisk. This allows very fast reads of the files that do not change during a session. I use Zenith's VDISK and set up a 1 megabyte ramdisk. I use a batch file to copy all of my menus and my working directories into the ramdisk. You must modify RBBS using CONFIG to reflect the new location of these files. 3. Use a FOSSIL driver. This is important when using high speed communications. I use X00.SYS on my board since it recognizes DesqView with the DV switch. I set up my Dual Standard or HST modem to communicate with the computer at 38400 baud. You can't go faster than 19200 without using a FOSSIL driver because RBBS does not support it. You will probably run into problems unless you have 16550 buffered chips also. I have increased my X00 transmit and receive buffer sizes to 4096 bytes each. The default is 1024 bytes. This allows more effective utilization of the clock ticks that each window gets. You may be able to increase them more depending on how much base memory you have available. 4. Set "Dos Buffers For EMS" to 0 in the DesqView setup if you are not running on a network. This setting made no difference when I was using ADCACHE, but made a considerable difference when using Super PC-Kwik. ══════════════════════════════════════════════════════════════════════════════ ┌─────────────────┐ │ RBBS-PC TIP# 3 │ └─────────────────┘ PROBLEM: I am having trouble getting X00.SYS to work properly. SYMPTOMS: X00 is difficult to setup to achieve optimal performance. SOLUTION: X00 works very well, but can be difficult to setup properly. You need to use a fossil driver in order to use a baud rate higher than 19200. I use X00 to enable my ports to run at 38400 baud. My command line is as follows: DEVICE=C:\RBBS\FOSSIL\X00.SYS E 0=3F8,IRQ4 1=2F8,IRQ3 B,0,38400 B,1,38400 T=4096 R=4096 DV F=15 This command line can be commented as follows: DEVICE=C:\RBBS\ROSSIL\X00.SYS (Calls X00.SYS from my subdirectory) E (Eliminates the sign-on screen from X00) 0=3F8,IRQ4 (Sets up first serial port at 3F8 and using IRQ4) 1=2F8,IRQ3 (Sets up second serial port at 2F8 and using IRQ3) B,0,38400 (Locks first serial port at 38400 baud) B,1,38400 (Locks second serial port at 38400 baud) T=4096 (Sets transmit buffer to 4096 bytes) R=4096 (Sets receive buffer to 4096 bytes) DV (DesqView pause which releases clock ticks when idle) F=15 (Sets 16550 FIFO to 15 bytes rather than default of 8) NOTE: Newer versions of X00 have bug fixes along with better performance with DesqView. ══════════════════════════════════════════════════════════════════════════════ ┌────────────────┐ │ Communications │ └────────────────┘ ══════════════════════════════════════════════════════════════════════════════ ┌────────────────────────┐ │ Communications TIP# 1 │ └────────────────────────┘ PROBLEM: Connect problems when using MNP-5 modems. Sometimes the speed is slower than other times. SYMPTOMS: When calling a BBS that is using a U.S. Robotics HST modem using a 2400 baud MNP-5 modem, sometimes the connection will be at 2400 baud and sometimes it will be 1200. In both cases the connection will be a "reliable connect". SOLUTION: Some 2400 baud MNP-5 modems are not fully compatible with the MNP protocol. Generally these were earlier modems, but I know of one case where the modem was a current production model. The solution is to have the BBS operator change his S15 register to 64. This allows compatiblity with these modems. This register change must be done on the HST modem, not on the 2400 baud modem. ══════════════════════════════════════════════════════════════════════════════ ┌────────────────────────┐ │ Communications TIP# 2 │ └────────────────────────┘ PROBLEM: Download speeds of ZIP files seem slow when using a 2400 baud MNP-5 modem. SYMPTOMS: When downloading from some BBS's the download speed of ZIP files is about 280 cps. From other boards only about 250 cps is possible. SOLUTION: MNP-5 compression is not effective on ZIP files. In fact, if you try to compress a ZIP file, things actually slow down. As a result, most boards disable MNP-5 compression. You can still achieve an error correcting link, but there will be no compression. Under this scenario you will achieve about 280 cps download speeds at the expense of screen update speed. The screens full of menus are not compressed either! On my board, MNP-5 compression is enabled. If you call in with MNP-5 your screen updates will be very fast, but your downloads of ZIP files will be in the 250 cps area. If you download Text or ASCII files, you may achieve rates as high as 500 cps. The solution is to defeat compression on the callers end when you want to download ZIP files. There is usually an "AT" command to defeat MNP-5 compression. Read your manual. If you intend to do a lot of downloading, defeat MNP-5. If you are just calling to browse, leave it on. You now have the best of both worlds. ══════════════════════════════════════════════════════════════════════════════ ┌────────────────────────┐ │ Communications TIP# 3 │ └────────────────────────┘ PROBLEM: Download speeds from some HST boards are not as fast as on other HST boards. SYMPTOMS: Download speeds from some HST boards run up to 1700 cps. Others can achieve only about 900-1100 cps. SOLUTION: U.S. Robotics manufactured two HST modems. The old modem was an HST 9600. The newer model was an HST 14400. The 9600 used a 9600 baud forward channel and a 300 baud back channel. The 14400 used a 14400 baud forward channel and a 450 baud back channel. After you sign off the board, do an ATI6. at the bottom of the screen you will see 9600/300 or 14400/450. This will tell you what type of modem you hooked up with. There are a lot of old HST's out there. There really is no solution to this problem unless you want to send your favorite SYSOP about $500.00 for a new HST. NOTE: It is possible that the SYSOP doesn't have his modem set up correctly, but I have found that to be somewhat rare. Normally that won't exact that much performance loss. If the SYSOP has an HST9600 there really isn't much he can do. ══════════════════════════════════════════════════════════════════════════════ ┌────────────────────────┐ │ Communications TIP# 4 │ └────────────────────────┘ PROBLEM: DSZ/Zmodem refuses to work with my computer system. SYMPTOMS: When using DSZ/Zmodem, it refuses to recognize the serial port. No communication occurs and I get bumped out of the program. SOLUTION: I ran into this problem with DSZ/Zmodem on my machine. The problem is that I was using a non-standard Port/IRQ combination. My system uses COM3 and IRQ5 for the modem. In order to support this combination you must invoke DSZ with the portx parameter. My command line to invoke DSZ from Qmodem is as follows: DSZ portx 3e8,5 speed %1 rz -rr This sets up DSZ to use COM3 and IRQ5. DSZ is case sensitive! Do not use upper-case letters for parameters. ══════════════════════════════════════════════════════════════════════════════ ┌─────────┐ │ Doorway │ └─────────┘ ══════════════════════════════════════════════════════════════════════════════ ┌─────────────────┐ │ Doorway TIP# 1 │ └─────────────────┘ PROBLEM: When I use Doorway to drop to dos, the screen for applications such as PC Shell not right. This problem only occurs when running two or more nodes of RBBS-PC under DesqView. SYMPTOMS: When doing a remote drop to dos and using a "mis-behaved" program such as PC Shell, half of the screen is black. Sometimes the screen of another node will be seen remotely. SOLUTION: Set the "Virtualize text/graphics" to "Y" in the DesqView setup for each node of RBBS-PC. Normally RBBS-PC does not require this since it does not do direct screen writes. However, when you run a program remotely using doorway, all of the programs you run may not be "well-behaved". By telling DesqView to Virtualize everything, you will force the program to behave itself, even in a door. ══════════════════════════════════════════════════════════════════════════════ ┌─────────────────┐ │ Doorway TIP# 2 │ └─────────────────┘ PROBLEM: Typing during a screen update will produce garbage characters. SYMPTOMS: During a remote screen update, if a character is pressed, the screen will be jumbled up. If you wait until after the screen has been updated, everything works normally. SOLUTION: There are two things which I have done to eliminate this problem. The first is to make sure that the FIFO of the 16550 on the BBS is enabled to 15. I use X00.SYS on my system. The default FIFO initialization is 8. You must use the F=15 switch to enable 15 bytes of buffering. The second thing which seems to help is to use XU to enable the Fossil before running Doorway. My batch file looks like this: XU PORT:0:ON DOORWAY COM1F ... (Your Doorway switches go here) XU PORT:0:OFF The COM1F was added with Doorway 2.06Beta to allow use of a fossil driver, however it appears that Doorway cannot turn the fossil on and off by itself. When RBBS shells, it turns the fossil off. It then turns it back on when it resumes normal operations. By using XU to turn the fossil on, Doorway benefits from its use. After making these changes, I was unable to introduce any errors into my screen updates. If you do not have Doorway 2.06, I suggest that you upgrade. ══════════════════════════════════════════════════════════════════════════════ ┌──────────┐ │ Reconfig │ └──────────┘ ══════════════════════════════════════════════════════════════════════════════ ┌──────────────────┐ │ Reconfig TIP# 1 │ └──────────────────┘ PROBLEM: When I use Reconfig in combination with a cache, the configuration is not changed. SYMPTOMS: When Reconfig does a warm boot after changing the Config.Sys and Autoexec.Bat files, the changes are not made. The computer boots up with the old configuration. This only happens when using a cache. SOLUTION: This problem occurs because of "write caching". PC-Cache 6.0, ADCACHE, and Super PC-Kwik all use write caching which caches all disk writes as well as disk reads. PC-Cache 6.0 however has write caching as its default. On some machines, the warm boot will occur before the cache has written the changes to the disk. This may depend on the speed of the machine as well. The solution is either to disable write caching or to flush the cache before rebooting. I elected not to use write caching since Reconfig does not have a convenient place to flush the cache. Other programs may be different. ══════════════════════════════════════════════════════════════════════════════ ┌──────────┐ │ Hardware │ └──────────┘ ══════════════════════════════════════════════════════════════════════════════ ┌──────────────────┐ │ Hardware TIP# 1 │ └──────────────────┘ PROBLEM: After installing a new hard or floppy drive, the unit doesn't work. I have checked my drive select jumpers and they are fine. SYMPTOMS: The floppy drive refuses to read disks, the hard drive acts like it isn't hooked up. SOLUTION: Check your cables! Zenith normally uses cables with no "twist". You then set the drive select jumpers to the physical location of the drive. Example: Drive A: would be DS0, and Drive B: would be DS1. IBM uses a cable which "twists" the drive select lines to fool the first drive. Example: Drive A: would be at the end of the cable and be DS1, and Drive B: would be before the twist and be DS1 also. If you are using "twist" cables which IBM likes to use, make sure you are using a cable with the proper twist. If you are like me, you didn't know there was a difference. IBM twists wires 25 through 29 for a hard drive cable and wires 10 through 16 for a floppy drive. Using the wrong cable can cause many problems. ══════════════════════════════════════════════════════════════════════════════ The End.